Loadstar 145/145.d81/t.disc b

Text File | 2022-08-26 | 25KB | 909 lines

    Explorations on IFLI

     by Adrian Gonzalez
      and Mike Gordillo


    Adrian Gonzalez is a true
Commodorian, a rare breed in his
native country of Mexico.  He has
spent the past year or so converting
.gif and .jpeg files into the IFLI
format on the C64.  His endeavours
have allowed many a C64 owner to
enjoy high quality images.


    [Mike:] Adrian, before we start,
can you give us some background on
what IFLI is and  how it achieves
such stunning images?

    [Adrian:] Sure thing.  A little
multicolor bitmap mode and FLI mode
background is in order too.  Images
in the 'regular' multicolor bitmap
mode (MCBM from now on) are divided
in cells or blocks that are 4 pixels
wide and 8 pixels tall.  The screen
is split into 40 columns of these
blocks horizontally and 25
vertically, giving a total of 1000
4x8 pixel cells or blocks.  A pixel
in one of these blocks can have any
one of 3 colors common to the entire
block, or the background color,
common to the entire screen.  A FLI
picture is similar to a regular MCBM
picture in that it has the same
resolution (160x200), however, it is
more flexible in terms of how many
colors you can use in each 4x8
character block.  This flexibility is
achieved through complex timing
tricks which I'd rather explain in a
future article, but I'll give a very
brief overview of what they make the
VIC-II do.  Basically, the trick is
to fool the VIC chip into fetching
the screen memory data on every
rasterline.  This screen memory data
is responsible for 2 of the 4 colors
available on each 4x8 character block
in MCBM (bit pairs '01' and '10').
So this basically divides each 4x8
cell of MCBM into eight 4x1 cells,
making the VIC chip fetch a different
pair of colors from screen memory for
each rasterline (each 4x1 cell).
This trick gets rid of most of the
restrictions that MCBM imposes, since
now 2 of the 4 pixels in every cell
can have any one of the 16 available
colors.  Chances are the colors
needed for the other two pixels will
be available from either screen
memory, color memory or the
background color.  This flexibility,
of course, does not come without a
price:  storage.  This technique
multiplies the amount of memory
needed for screen data times 8,
adding 7000 bytes when you compare
with a standard koala paint file.
Fortunately, the 8000 bytes needed
for screen memory and the 8000 for
the bitmap fit just right on one 16k
bank (remember the VIC can only 'see'
16k at a time).

    If you are new to these software
screen modes, I recommend you read
the previous part again, especially
because once you get the grasp of FLI
mode, IFLI is a snap.  IFLI mode is
basically two FLI pictures being
rapidly alternated to give the
illusion of more colors.  So where
does the added resolution come in?
Thanks to the VIC-II's hardware, it
is possible to shift the screen up to
7 hi-res pixels horizontally, even
when in MCBM.  The trick in IFLI is
to display one FLI picture for an
entire screen refresh, then display
the second FLI picture shifted one
hi-res pixel to the right on the next
redraw.  The effects of this are not
so obvious, so I'll illustrate with
an example.  Suppose you have the
first line of FLI picture A and FLI
picture B and it looks like this:

 First line of FLI picture A:
  K    G    Y    O   . . .

 First line of FLI picture B:
  G    G    Y    O   . . .

When you alternate them, shifting
picture B one hi-res pixel to the
right you get:

  K    G    Y    O  . . .
     G    G    Y    O
 ------------------------------
 K KGG G GYY YOO . . .

 Where:
 K = Black pixel
 G = Green pixel
 Y = Yellow pixel
 O = Orange pixel

    The resulting line has pixels
that are as wide as high resolution
pixels, and that may have colors that
are combinations of the c64's 16
standard colors. It is evident from
this example that IFLI's strengths
lie in reproducing images with smooth
color shades.  The downside of IFLI
is that it flickers, and depending on
the colors that are being alternated,
the flicker can go from barely
noticeable to a stroboscopic light
show.  With this in mind, however,
this display mode can produce some of
the most stunning images that have
ever been displayed on our beloved
C64.  After this brief introduction I
hope the interview will make a little
bit more sense, so let's get on with
it.


    [Mike:] Adrian, I know you do the
bulk of your conversions on other
platforms for the sake of
expiediency.  However, I'm more
generally interested in how the
pictures get down to the C64 in terms
of the actual display on the C64.

    [Adrian:] Well, I start out by
doing careful color analysis on my
Amiga.  This involves pre-processing
the images in programs such as The
Art Department Professional, in order
to adjust the brightness, contrast,
color and size of the source images.
After that, I feed the images to a
conversion utility I wrote that tries
(as best as possible) to map the
colors from the original image to
combinations of the 16 colors of the
c64, taking many factors into
consideration, such as flicker.  The
conversion program has several
settings, which have to do mostly
with dithering and flicker reduction.
It is not always perfect, and the
problem of IFLI flicker is never
truly defeated, but I'm generally
satisfied with the results.


    [Mike:] Yes, they are beautiful
conversions, but I could never get
them to display with any other IFLI
viewer.

    [Adrian:] Since there is no
standard data format for IFLI
pictures I had to come up with my
own.  My ifli's load at $2000, then
the code moves them to the higher
memory and depending on how big they
are, of course, they get depacked
accordingly.


    [Mike:] Argh, they are packed?

    [Adrian:] Of course they are
packed.  When was the last time you
saw two of them having the same size?
:)

    [Mike:] What kind of packer did
you use?

    [Adrian:] They are packed using a
very simple RLE routine.  If you want
you can use the routines in my viewer
to depack them for you.  They'll set
everything up in the right place.
(e.g. $4000-7fff, $c000-$ffff and
$d800-$dbff).  If anybody is
interested in these routines or the
source code for the viewer, feel free
to mail me and I'll send them your
way.

    [Mike:] Why did you split the
data over those addresses?  Is it
safe to assume that IFLI data is
composed of two 16 kbyte blocks for
pic data and then comes the color
info at $d800 on up?

    [Adrian:] Yeah, you can look at
it that way.  It's actually two 8k
blocks containing the bitmaps and two
8k blocks containing the screen
memory.

    [Mike:] Ah, I see.  There is one
FLI pic portion in each 8k bitmap and
one 1k block for color memory that is
common to both images.

    [Adrian:] Yes, but you know, it
might be interesting if it were
possible to change color memory as
well.  It would give us a slight
boost in the number of apparent
colors.

    [Mike:] Could you explain exactly
how, and wouldn't any further memory
tweaking complicate matters more?
Maybe you would need to not use the
entire screen?

    [Adrian:] Oh, just mumbling out
loud :).  In practice there is no
time to change color memory on the
fly.  Also, it doesn't matter if you
do IFLI's smaller than the entire
screen (say 1/3 screen IFLI) because
you still have data scattered all
over the same ranges I described
earlier.  The IFLI data must be
placed at certain spots in memory so
that the VIC-II chip can properly
fetch it.

    [Mike:] Ok, I understand, but
this 1/3 IFLI screen proposal
intrigues me greatly.  I hear "less
than full-screen" IFLI's may be
doubled-over onto themselves, thereby
giving even more colors or perhaps
leading to run-time IFLI animations.

    [Adrian:] This is a possibility,
but you would have even more flicker
than regular IFLI.  I'm not even sure
if the logistics involved will allow
even a 1/3 IFLI to be doubled over.

    [Mike:]> Well, if the CPU proves
too slow, what about using the speedy
REU to do the job?

    [Adrian:]] Interesting, the
problem is that since I'm not lucky
enough to own one, I do not know how
much overhead it takes to set up the
REU for multiple transfers. For
example, if I wanted to transfer 512
bytes of screen memory, then
reprogram the R